Virtual computing environments allow multiple virtual machines (VMs) to be run on a single physical platform (“host”) and to share physical resources. Some virtual computing environments allow configuring the VMs in a way where the total amount of memory designated for use by the VMs is bigger than the actual amount of memory available on the host. This is referred to as memory over-commitment, and it allows packing more VMs onto a single host.
Each VM has a guest operating system (OS) that allocates the physical address space of the VM, which is divided into addressable physical page numbers (referred to herein as “guest physical page numbers”), to applications and devices running in the VM. Each such application or device is allocated a virtual address space, which is divided into addressable virtual page numbers (referred to herein as “guest virtual page numbers”), each of which may have a mapping to a guest physical page number or to a location on a virtual disk of the VM known as a swap space. The use of the virtual address space allows the guest OS to provide a contiguous address space and also to over-commit the guest physical memory, which may cause swapping out of guest physical pages to allow them to be repurposed between applications and devices running the VM.
Just as a guest OS maps guest virtual page numbers to guest physical page numbers, a virtualization software layer running in the host, commonly known as and referred to herein as a hypervisor, maps the guest physical address space of each VM to the host physical memory space (also referred to as “machine memory space”), which is divided into addressable host physical page numbers (referred to herein as “machine page numbers”). Over-commitment of the machine memory may lead to swapping out of machine pages to a swap space managed by the hypervisor to allow them to repurposed between VMs running in the host.
When both the guest OS and the hypervisor have over-committed their respective physical memory, a problem known in the art as “double swapping” may occur. This problem is encountered when the hypervisor swaps out a machine page to its swap space and the guest OS subsequently attempts to swap out a guest physical page that is mapped to the swapped-out machine page. When the guest OS attempts to swap out a guest physical page that is mapped to the hypervisor swapped-out machine page, the hypervisor swapped-out machine page is read back into memory from the swap space of the hypervisor, only to be swapped out once more to a swap space on the virtual disk that is managed by the guest OS. This sequence of events has several costs: (1) allocation of a machine page for swapping in the hypervisor swapped-out machine page when the host is presumably under memory pressure; (2) swapping in data that is already stored persistently, only to be swapped out once more to persistent storage; and (3) unexpected latency experienced by the VM.